IBIS Macromodel Task Group

Meeting date: 06 October 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                            * Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                       * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- None.

--------------------------
Call for patent disclosure:

- None.
-------------
Review of ARs:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Mike L: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:
  
Item #6: Info, Out, InOut BIRD draft.
- Arpad: Last week we decided:
  - No additional "severity" indicator parameter.
  - The list of special Model Specific parameters would have to include all of
    the parameters requiring special handling, even those parameters that are
    for "above and beyond" features not required for the basic simulation flow.
- Arpad: Walter has raised a new question regarding the analog modeling.
  - Walter suggested adding a new subparameter under [Algorithmic Model] in the
    IBIS file.
  - I agree with his suggestion, but we need to discuss it. [below]
- Arpad: [sharing a draft of the BIRD]
  - Today I want to work on the final verbiage.
- Discussion: Parser instructions/requirements added to the "Any Other
  Background Information:" section of the BIRD draft.
  There was general agreement that the parser should issue an error if the new
  Special_Param_Names parameter contained the name of a parameter that was not
  found in the Model Specific parameters section.  There was debate over whether
  the parser should issue a warning or a note if the Special_Param_Names exists
  at all.  Ambrish suggested that it should issue a warning to make sure the
  user was aware of potential portability issues.  Walter disagreed and said
  that we didn't want to punish model makers for using the new parameter.  Mike
  L. noted that "forcing" model makers to use this feature and then issuing
  parser warnings might be ill-advised.  He noted that it was really up to the
  EDA tool, not the parser, to process the information from Special_Param_Names
  and present the user with the correct compatibility information.  Bob R. was
  asked to define the difference between "note" and "caution" in the parser
  output.  Bob said that notes are always printed, and caution messages must be
  enabled by setting a command line flag.  He noted that their actual "levels"
  were similar.  The thing being flagged in either case was not a technical
  requirement.  Radek stated that caution would probably be a better choice than
  note, were it not for the fact that notes were always displayed and cautions
  were not.  But he said he was fine with using note in this case.  Arpad and
  Mike L. suggested that the details could be ironed out in the IBIS quality
  meeting, but Walter was firm that he wanted the text of the BIRD draft to
  state that a note would be issued and not a warning.  Arpad made the change
  and noted that we could return to this discussion later.  Walter suggested
  that we had to complete the text of the rest of the BIRD to fully work out
  exactly what happens when a parameter is listed in this new
  Special_Param_Names.
- Discussion: Final wording of the "Definition" and "Usage Rules" for the new
  Special_Param_Names.
  Arpad presented several proposals for defining the parameter.  The group
  worked on the text real-time and arrived at the following:
  
  Definition - This reserved parameter identifies, by name, all Model_Specific
  parameters that require EDA tools to perform special handling that is not
  described in the IBIS specification.
  
  Usage Rules - If the .ami file in which this reserved parameter appears
  contains any Model_Specific parameters associated with special operations that
  the model expects the EDA tool to perform beyond what is described by the IBIS
  specification, the name of all such Model_Specific parameters must be listed in
  this reserved parameter.
  
- Bob R - I think the title of the BIRD should now officially be changed.
- Arpad - [Changed title: New IBIS-AMI Reserved Parameter Special_Param_Names.]
   - I will clean up this draft based on these discussions.
   - Walter, would you like to discuss your analog model issue?
 
- Walter: [sharing email on the topic]
  - Issue: IBIS 5.1, and even IBIS 6.0, is not going to describe the analog
    models with sufficient accuracy.
  - IBIS 6.0 now allows us to use s-parameters for AMI modeling, but there are
    still going to be models that require proprietary simulators.  Many of our
    tools have the ability for models to point to other simulators, whether they
    do it in the IBIS file or somewhere else.
  - But that's an IBIS [Model] that does not contain an adequate description of
    the analog behavior of the buffer.
  - Shouldn't we have some method for the model maker to advertise that to the
    user?  That is, to say, "you can't just take the I/V and V(t) curves and
    get a model with sufficient accuracy to do your job."
  - I propose adding a new IBIS subparameter, perhaps under [Algorithmic Model],
    that would advertise to the user that the analog [Model] is insufficient.
  - Proposed name: IBIS_Analog_Model_Incomplete
    - Could be true, false, etc., we can work out the exact syntax.
  - Tell the model maker community that when you have a [Model] that's
    insufficient you should advertise it.
- Discussion:
  Bob R. said that a [Model] that needed this subparameter was effectively dead
  and shouldn't be released, except that there must be some special parameters
  that work in somebody's tool.  Walter concurred and said this was often done
  with special keywords hidden behind comment characters, because the parser
  has no way of handling "special" keywords in the .ibs file the way it does
  for dealing with Model Specific .ami parameters.  Walter wondered if we might
  not want to add something equivalent to Model Specific parameters to the .ibs
  file.  Arpad and Bob R. both suggested that this proposal should be written
  up separately from the Special_Param_Names BIRD, despite the fact that they
  dealt with somewhat similar issues.  Michael M. noted that a similar new
  subparameter could reasonably be defined for [Package Model], and any other
  area where the specification might obligate the model maker to provide some
  data that would not be entirely useful or complete.
- Arpad: I will work on cleaning up a new draft of the Special_Param_Names BIRD.
  - We can work on this analog modeling proposal under a separate BIRD.
  - Thank you all for joining.

AR: Arpad to clean up draft 14 of the Special_Param_Names BIRD and send it to
    Mike L. for posting to the ATM website.

-------------
Next meeting: 13 October 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
